Dear @mrdeep1
Thanks again for realizing this so quickly -- the more I am sorry for coming back this late! Neither of the two development teams that have the integration of this in their backlog were able to schedule the task in a sprint so far. Hence, I used some time at the IETF Hackathon to test it out myself and start with feedback.

The basic mechanism is working well! I only noticed the automatic 4.04 still being sent when the server is shut down gracefully (e.g., Ctrl+c). It still resumes the notifications after the 4.04. I think it should be either a full shutdown with 4.04 and no resume or an intentional restart/hibernate without 4.04 and resume. I still need to think some more about this.

Now that I have the basic setup working, I will try to test and review some more. Please bear with me and just leave this PR open :)

Thanks for doing the testing so far - much appreciated. I did not really think through the 4.04 "issue. As I see it

1. Server shuts down and does not immediately restart
2. Server does a clean shutdown and is shortly restarted
3. Server does an unclean shutdown and is then restarted

For 1), 4.04 should be sent out (RFC7641 is a SHOULD for when the resource is deleted) RFC7641 4.2.

For 2) the 4.04 should not be sent out.

For 3) nothing is expected to be sent out unless 2) failed part way doing the shutdown.

To differentiate between 1) and 2), perhaps 1) could continue using SIGTERM, but 2) could use SIGUSR2 (SIGUSR1 is planned for something else). Then the SIGUSR2 handler could call a new function - say - coap_observe_no_clear_down() which causes the 4.04 to not get sent out. Work for you?

I separately was thinking it made sense to move the current server application's tracking code into libcoap (enabled as a configurable option) but still provide coap_observe_track() should the application was to do its own database tracking. What do you think?

Added in coap_observe_no_clear_down() and SIGUSR2 support in coap-server for not sending out 4.04 for active observations when closing coap-server down.

@mkovatsc I have moved most of the application persist logic into the libcoap logic (configurable to enable it, by default enabled) so that only 2 functions need to be called within the application - coap_persist_startup() and coap_persist_stop() if you want to maintain the persist information if the server is cleanly shutdown.

Application persist callbacks are still available if required (support always available), but there has been some parameter updates (and some function name changes).

Any feedback welcome.